1. The Field of the Invention
The field of the invention generally is network packet processing on a general purpose computer system. More particularly, the field of the invention relates to a personal computer connected to a communications network and having a layered architecture for handling packets of network data that roughly corresponds to the lower layers of the ISO model. Specifically, the invention relates to methods of increasing system processing efficiency by reducing the amount of copying that occurs between different layers of software during network packet processing.
2. Present State of the Art
The effectiveness of general purpose stand alone computers, such as the personal computer found in most office environments and laptop computers increasingly used by professionals requiring portability, has been substantially improved by allowing communications between machines over a communications network. Such networking of computers allows the sharing of resources found on one computer with other computers in the network. For example, storage areas having files, printers, modems, and other resources may all be advantageously shared.
Data that is shared between computers is sent in packets across the physical network connection and read by destination computers. Such packetized network data may be requests for shared resources, data, such as a file, or other information that must be communicated from one computer to the other. As used herein, the term "network data" refers to data or information that is actually transmitted over the communications network between different computers.
On a particular computer or node of the network, a network interface card (NIC) or network card monitors the physical communications channel for packets destined for that computer as well as transmits packets of network data destined for other computers. Software components run on the node computer under direction or control of the operating system or architecture for managing and controlling the network card operations. Furthermore, other software components exist to further abstract the network communications channel and provide more and more general networking interfaces for higher layers using their services. The layered approach allows compartmentalization and easier development of network applications.
One model used to provide a structure for layered software component development is the seven-layer ISO model that is well known in the art. While actual implementations of the ISO model do not necessarily rigidly isolate each particular layer as a separate component exposing it's own interface to layers above and below, the concepts of the model are generally applicable. With respect to the present invention as currently embodied, the lower layers of the ISO model are at issue, namely, the data link layer implemented by a network card device driver, and the transport and network layers implemented as a transport protocol driver.
Lower level networking functions, such as are discussed throughout this application with respect to controlling a network card and initial processing of packetized network data, are handled by special system software components called drivers that integrate with a host operating system according to a specific architecture and have special privileges for accessing system resources. Throughout this application, reference will be made to the Windows NT.RTM. operating system available from Microsoft Corporation and to its specific architecture wherein lies one embodiment of the present invention. Such drivers run in "kernel mode," meaning they have higher privileges and access to system resources than do "user mode" application process threads. While specific reference is made to Windows NT.RTM. concepts and terminology, those skilled in the art will recognize that many, if not most, operating systems share similarities relevant to the environment of the present invention.
Because there are different types of transport protocols developed over time by different entities for different reasons, there may be different types of transport protocol drivers acting as software components running on a single host computer system in order to provide the necessary networking capabilities for a given installation. Some common transport protocols include TCP/IP, IPX, AppleTalk.RTM., and others. Each transport protocol driver will communicate with one or more individual network card device drivers in order to send network data over a communications network and receive incoming packets from the communications network.
Furthermore, because there are a multitude of network cards provided by numerous manufacturers, there are a corresponding large number of potential network card device drivers. In order to support full connectivity to the transport protocol drivers, each network card device driver must support the ability to communicate with each different type of transport protocol driver. Because of the complexity of many different variations that could conceivably be connected together due to the layered component approach, building such is drivers can be a time intensive process and the nature of the different inter-faces each driver must use is illustrated in FIG. 1.
FIG. 1 is a block diagram showing the structure of a plurality of network cards, network card device drivers, and transport protocol drivers that each must interact with system resources and a central database or registry having connectivity information in order to operate properly. Furthermore, each transport protocol driver must support each and every network card device driver for which it may be connected and in like manner each network card device driver must support communicating with each and every transport protocol driver to which it may be connected.
If a new transport protocol driver is introduced, each network card device driver wanting to support the new transport protocol driver may require modification to the source code followed by a re-release and distribution of the executable driver code. likewise, a new network card device driver may also require a similar re-release. Releasing and distributing software is an expensive process that software companies desire to limit as much as possible.
For example, passing network information arriving on network card 20 controlled by network card device driver 22 to the transport protocol driver 24 requires the transport protocol driver 24 and the network card device driver 22 to be fairly complex in terms of programming effort. This may take significant time for a developer or engineer to create. Note that the network card driver 22 must not only interact with the network interface card 20 but also have an interface 26 to the system resources 28 as well as an interface 30 to the registry 32 containing connectivity information. Through such interfaces and the programming entailed therein, the network card device driver 22 will receive an interrupt that a packet has been received or is available for receipt by having the system execute code in an interrupt handling routine previously registered that makes use of system resources such as RAM for storing the packet.
Furthermore, the network card device driver 22 will use the registry interface 30 to access the registry 32 connectivity information for determining which transport protocol driver(s) will receive the packetized network information. For purposes of this example, the transport driver 24 is the recipient as illustrated by connecting line 34. Note also that the network card device driver 22 must support or be able to communicate with other transport protocol drivers since a variety exist and it is not known at development time which transport protocol driver will be indicated in the control information found in the registry 32 for receiving the network data.
On the other hand, the protocol transport driver 24 must also interface with the system resources 28 and the registry 32 containing connectivity information. Again, in order to support the many available network card device drivers, each transport protocol driver will be a relatively complex software component since the precise network card device driver for interfacing is not known at the time of development.
One advance in the art that has reduced the complexity associated with developing transport protocol drivers and network card device drivers is that of an integrating component that provides an abstracted interface to transport protocol drivers developers and to network card device driver developers. FIG. 2 is a block diagram showing the introduction of an integrating component that reduces the complexity of transport protocol driver development and network card device driver development. In such an environment, an integrating component 36 will have a registry interface 38 for accessing a registry 32 of connectivity information and a system resource interface 40 for accessing system resources 28. Therefore, development of the network card device driver 42 for controlling network card 20 is greatly simplified. The network card device driver 42 must only support an interface 44 to the integrating component 36. In like manner, the transport protocol driver 46 is also further simplified as only an interface 48 to the integrating component 36 may be supported.
The complexity of interfacing directly with the system resources 26 and the registry 32 of connectivity information is now handled by the integrating component 36. Furthermore, the integrating component provides an interface to developers incorporating many services and functionality that will be common to network card drivers and transport protocol drivers allowing the drivers to be developed more efficiently.
Another inherent benefit is that all routing of packets between transport protocol drivers and network card device drivers is managed by the integrating component. A particular transport protocol driver or network card device driver does not need to know the specific interface of the other components processing the same network packet. In other words, any network card device driver written to the integrating component 36 will be able to communicate with any available transport protocol that is also written to the integrating component 36 as determined by the connectivity information contained in the registry 32 and vice versa with respect to transport protocol drivers communicating with network card device drivers.
Besides providing quicker transport network card device driver development, the use of an integrating component 36 also facilitates multi-platform support. The integrating component interface may be supported on many different platforms, effectively encapsulating the details of actual interfacing with the a particular operating system and environment. A driver developer generally needs to write the driver only one time and simply recompile the driver on any system that has the integrating component 36 supported thereon.
One technology for integrating network card device drivers to transport protocol drivers is the Network Driver Interface Specification (NDIS) technology implemented on the is Windows NT.RTM. operating system as the NDIS wrapper device driver. The NDIS technology is also supported on other systems, such as the Windows95.RTM. operating system, in order to support cross platform support of network card device drivers and transport protocol drivers. The integration component manages all interaction with system level services and hardware to further reduce development complexity of connected drivers. For example, the NDIS wrapper manages initial interrupt processing, system memory allocations to connected drivers, allocation to other hardware resources, etc. as well as providing packet routing capability between network card device drivers and transport protocol drivers.
While many benefits accrue from the use of an integrating component, such as the NDIS wrapper, during the processing of network data, certain behaviors are introduced that impair system efficiency. One such problem occurs due to the nature of interrupt processing done to service the network card and the different execution levels of the host processing system inherent therein.
Normally, a host operating system, such as Windows NT.RTM., operates at a normal or passive level wherein user processes and process threads execute on the host processor (or processors in a multi-processor system). Periodically, events occur that raise the execution level up to a "higher" level that preempts whatever is happening on the passive level. For example, a hardware interrupt will cause the system to begin executing code of an Interrupt Service Routine (ISR) at an execution level that is higher than passive level in order to service hardware.
In the Windows NT.RTM. operating system, execution levels, in general, are known as interrupt request levels or IRQLs and all hardware device interrupts have a level associated therewith known as a device interrupt request level or DIRQL. The highest level DIRQLs are reserved for critical operating system functions such as bus errors, system clock, etc. One form of general software interrupt runs at the Deferred Procedure Call (DPC) level which is above passive level but typically below the DIRQLs associated with hardware device interrupts. Examples of raised execution level processing includes receipt of network data from a communications network, context switching between process threads by the task manager so that another process or process thread may use the host CPU, etc.
Besides hardware interrupts, software interrupts may be scheduled by an ISR or other entity. Since interrupts of a lower level as well as other processing are masked when a host processor executes a particular ISR associated with a particular DIRQL, it is often important to end the high execution level associated with processing the hardware interrupt as soon as possible so that other waiting interrupts may be serviced. One common strategy is to have the ISR schedule a software interrupt to perform the bulk of processing to allow the ISR to be so written that it uses the least amount of host CPU time. In the Windows NT.RTM. environment, one form of general software interrupt processing code is referred to as a Deferred Procedure Call or DPC. A DPC is placed in a queue and runs at the dispatch level IRQL that will begin processing after all the DIRQLs have been cleared.
One problem associated with higher execution levels is that they do not allow safe access to certain system facilities. For example, a virtual memory manager's paged memory may only be accessed by threads running at the passive level in the NT operating system. The paged memory is not available to higher execution levels such as those associated with ISRs and DPCs. Therefore, network packets being received and processed in the DPC execution level, in many instances, cannot be fully processed before termination of the DPC level since paged memory is unavailable. To solve this problem, a transport protocol driver requires a portion of code running in the DPC level to copy the network data into a separate data structure for future processing by the transport protocol driver at the passive execution level. Copying the data into a separate data structure is required because there is no way to guarantee that the network data in the packet will not become overwritten once the DPC has finished execution. Since the network card device driver may immediately reuse the packet once the invocation session that initiated DPC level processing at the transport protocol driver is terminated, there is no guarantee that the data in the packet will be available once the transport protocol driver's DPC level code is exited.
Such data copying impacts system performance on a number of different levels. First, precious host CPU time is used to make the intra-system data copy from one buffer to another, second, excessive system memory resources are utilized in order to have the extra buffers for copying the data, third, system caches are excessively used by the copy operation impairing efficiency for other operations, and fourth, Translation lookahead Buffers (TLBs) are also excessively used impairing efficiency in address translation. It would be an advancement in the art to reduce intra-system copying so that more system memory is available for other uses and so that no CPU time is lost moving data from one location to another.